home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 88 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.3 KB
  1. Path: fido.asd.sgi.com!austern
  2. From: thp@cs.ucr.edu (Tom Payne)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Throwing an exception from within a si
  5. Date: 22 Jan 1996 09:43:19 PST
  6. Organization: University of California, Riverside Department of Computer Science
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4du0gr$8k8@galaxy.ucr.edu>
  9. References: <4dka2t$p6m@galaxy.ucr.edu> <4dltnb$mca@engnews1.Eng.Sun.COM>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 21 Jan 1996 18:26:35 GMT
  12. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMQPM1ky4NqrwXLNJAQFmMgH9G7mm4nggsNhUNW9wWFvo+lnrUYvTgF6F
  15.     5V+qcxbQTI6VN4aTDbvvmliWPZynJpGslNNdrPr0PwYUiTuIAAaOnw==
  16.     =6V3S
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. Steve Clamage (clamage@Eng.Sun.COM) wrote:
  20. : 
  21. : Suppose that function entry and exit are not atomic operations, which is
  22. : the case on all systems supporting C++ that I am aware of. The "critical
  23. : structure" is the stack frame. If asynchronous interrupts can occur, and
  24. : if you are going to require well-defined exception behavior from signal
  25. : handlers, then you must lock the entirety of every function preamble and
  26. : postamble. (You cannot know that an external signal won't occur.) That
  27.  
  28. If signal blocking and postponement is implemented with a couple of flags
  29. in the programs static area, we are looking at two writes and a test
  30. at the typical call and return.
  31.  
  32. : requirement not only slows down function calls, it adds to interrupt
  33. : latency.
  34.  
  35. : How expensive is it to lock and unlock every function entry and exit?
  36. : On some systems it is cheap. On others it is expensive. Considering that
  37.  
  38. I think that has to do with efficiency of the signal-blocking aspects
  39. of the signal handling library rather than an inherent limitation of
  40. the underlying architecture.
  41.  
  42. : a characteristic of OO programs is having many small functions, requiring
  43. : these locks could have a dramatic impact on program performance, even
  44. : for programs that don't want to throw exceptions from signal handlers.
  45.  
  46. If we use another flag to tell whether an exception-throwing handler
  47. has been installed, then we can bypass the signal blocking when the
  48. feature isn't used.  (Applications that can't tolerate the increased
  49. signal latency shouldn't throw exceptions from signal handlers.)
  50.  
  51. : What we put in the language standard is binding on all implementations. We
  52. : try to specify things that can be implemented efficiently on any likely
  53. : system. In addition, we try to specify features so that they have no cost
  54. : (or nearly no cost) if you don't use them. IMHO, guarantees about what you
  55.  
  56. Agreed!!
  57.  
  58. : can do in an asynchronous signal handler don't meet those criteria for
  59. : inclusion in the C++ standard.
  60.  
  61. That's a rather broad conclusion, given the discussion so far.
  62. Perhaps the fist implementation that comes to mind (for implementing
  63. exception throwing from signal handlers) doesn't meet those criteria,
  64. even with the patches suggested above.  Still, to dismiss the
  65. possibility of an efficient implementation for this and/or other
  66. asynchornous capabilities seems premature.
  67.  
  68. Tom Payne (thp@cs.ucr.edu)
  69. ---
  70. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  71.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  72.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  73.